System, method and computer program product for aggregating on-demand database service data

ABSTRACT

In accordance with embodiments, there are provided mechanisms and methods for aggregating on-demand database service data. These mechanisms and methods for aggregating on-demand database service data can enable embodiments to more flexibly summarize data. The ability of embodiments to provide such feature may lead to enhanced aggregation features which may be used for providing more effective ways of summarizing data.

CLAIM OF PRIORITY

This application is a continuation of U.S. application Ser. No.12/175,973, filed Jul. 18, 2008, which claims the benefit of U.S.Provisional Patent Application No. 60/950,808 entitled “ROLL UP SUMMARYFIELD (RSF) FUNCTIONAL SPEC AND) PROTOTYPE,” by Alan Ballard et al.,filed Jul. 19, 2007, the entire contents of both are incorporated hereinby reference.

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains materialwhich is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the Patent and TrademarkOffice patent file or records, but otherwise reserves all copyrightrights whatsoever.

FIELD OF THE INVENTION

The current invention relates generally to database systems, and moreparticularly to summarizing data in database systems.

BACKGROUND

The subject matter discussed in the background section should not beassumed to be prior art merely as a result of its mention in thebackground section. Similarly, a problem mentioned in the backgroundsection or associated with the subject matter of the background sectionshould not be assumed to have been previously recognized in the priorart. The subject matter in the background section merely representsdifferent approaches, which in and of themselves may also be inventions.

In conventional database systems, users access their data resources inone logical database. A user of such a conventional system typicallyretrieves data from and stores data on the system using the user's ownsystems. A user system might remotely access one of a plurality ofserver systems that might in turn access the database system. Dataretrieval from the system might include the issuance of a query from theuser system to the database system. The database system might processthe request for information received in the query and send to the usersystem information relevant to the request.

There is often a desire to flexibly implement various functionality inthe foregoing database frameworks. To provide such functionality,providers of such database systems must generally build-in thefunctionality themselves. One example of such functionality is theability to summarize data of the database system.

BRIEF SUMMARY

In accordance with embodiments, there are provided mechanisms andmethods for aggregating on-demand database service data. Thesemechanisms and methods for aggregating on-demand database service datacan enable embodiments to more flexibly summarize data. The ability ofembodiments to provide such feature may lead to enhanced aggregationfeatures which may be used for providing more effective ways ofsummarizing data.

In an embodiment and by way of example, a method is provided forreceiving a summary definition including a function for summarizing dataand information specifying a plurality of child records of an on-demanddatabase service. Data from the child records is aggregated to form anaggregate based on the summary definition. To this end, the aggregatemay be displayed, in response to a request for viewing the aggregate.

While the present invention is described with reference to an embodimentin which techniques for aggregating on-demand database service data areimplemented in an application server providing a front end for amulti-tenant database on-demand service, the present invention is notlimited to multi-tenant databases or deployment on application servers.Embodiments may be practiced using other database architectures, i.e.,ORACLE®, DB2® and the like without departing from the scope of theembodiments claimed.

Any of the above embodiments may be used alone or together with oneanother in any combination. Inventions encompassed within thisspecification may also include embodiments that are only partiallymentioned or alluded to or are not mentioned or alluded to at all inthis brief summary or in the abstract. Although various embodiments ofthe invention may have been motivated by various deficiencies with theprior art, which may be discussed or alluded to in one or more places inthe specification, the embodiments of the invention do not necessarilyaddress any of these deficiencies. In other words, different embodimentsof the invention may address different deficiencies that may bediscussed in the specification. Some embodiments may only partiallyaddress some deficiencies or just one deficiency that may be discussedin the specification, and some embodiments may not address any of thesedeficiencies.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a method for aggregating on-demand database service data,in accordance with one embodiment.

FIG. 2 shows a method for aggregating on-demand database service data,in accordance with another embodiment.

FIG. 3 shows a method for aggregating on-demand database service data,in accordance with another embodiment.

FIG. 4 shows an interface including a table for aggregating on-demanddatabase service data when the data includes data of multiplecurrencies, in accordance with one embodiment.

FIGS. 5A-5E show interfaces for creating a new summary field on amaster-detail relationship, in accordance with one embodiment.

FIG. 6 illustrates a block diagram of an example of an environmentwherein an on-demand database service might be used.

FIG. 7 illustrates a block diagram of an embodiment of elements of FIG.6 and various possible interconnections between these elements.

DETAILED DESCRIPTION General Overview

Systems and methods are provided for aggregating on-demand databaseservice data.

It is often desired to flexibly implement various functionality in theforegoing database frameworks. To provide such functionality, providersof such database systems may either build-in the functionalitythemselves or provide the user the ability to customize the framework toaccomplish the same. One example of enhanced functionality is theability to summarize data of the database system. Thus, mechanisms andmethods provided herein for aggregating on-demand database service datacan enable embodiments to more flexibly summarize data. The ability ofembodiments to provide such feature may lead to enhanced aggregationfeatures which may be used for providing more effective ways ofsummarizing data.

Next, mechanisms and methods for aggregating on-demand database servicedata will be described with reference to exemplary embodiments.

FIG. 1 shows a method 100 for aggregating on-demand database servicedata, in accordance with one embodiment. As shown, a summary definitionincluding a function for summarizing data and information specifying aplurality of child records of an on-demand database service is received.See operation 102.

In the context of the present description, an on-demand database servicemay include any service that relies on a database system that isaccessible over a network. In one embodiment, the on-demand databaseservice may include a multi-tenant on-demand database service. In thepresent description, such multi-tenant on-demand database service mayinclude any service that relies on a database system that is accessibleover a network, in which various elements of hardware and software ofthe database system may be shared by one or more customers. Forinstance, a given application server may simultaneously process requestsfor a great number of customers, and a given database table may storerows for a potentially much greater number of customers.

Further, in the context of the present description, a summary definitionrefers to any definition for summarizing data. For example, in oneembodiment, the summary definition may include at least one function forsummarizing data and master/detail information specifying a plurality ofchild records. In another embodiment, the summary definition may includeat least one rule or filter specifying a subset of the child records tobe aggregated in the summary. Additionally, the summary definition maybe associated with a roll-up summary field and/or a parent recordassociated with a child record. In this case, child records refer to anyrecords that are categorized under a parent record.

Further, in the context of the present description, a roll-up summaryfield refers to any field type that aggregates a record count or fieldvalue from related child records. For example, in one embodiment, theroll-up summary field may include a custom account field titled “TotalNumber of Contacts” that displays a record count of the total number ofcontacts directly related to the account.

With further reference to FIG. 1, the data from the child records isaggregated to form an aggregate based on the summary definition. Seeoperation 104. Additionally, the aggregate is displayed, in response toa request for viewing the aggregate. See operation 106.

It should be noted that the summary definition may be createdindependently of the aggregating. In one embodiment, the summarydefinition may be created by a system administrator on behalf of acommunity of users. Because the summary definitions may be pre-created,the aggregation may be performed in advance of the request to displaythe value.

Thus, the aggregating may be performed, at least in part, before therequest is received. In one embodiment, a first portion of theaggregating may be performed before the request is received, and asecond portion of the aggregating may be performed after the request isreceived. Additionally, the aggregating may be performed in response toa change in the data of the child records or a change in the summarydefinition.

In one embodiment, the data of only the specified child records may beaggregated. As an option, the specified child records for summarizationmay be user selected. In this case, the specified child records may beselected utilizing a user interface. For example, a user interface maybe presented to a user such that the user may select child records aspart of the summary definition via a rule.

It should be noted that the function for summarizing the data andinformation may be based on various criteria. In one embodiment, thefunction for summarizing the data and information may include a formula.In this case, a parent record may include a formula populated from asummary field. For example, a formula in the parent may use a summaryfield as part of a calculation. In one embodiment, a formula in theparent may use a summary field to compute an average by dividing the sumof a child field (i.e. one summary field) by a count of child rows (i.e.another summary field).

As an option, the child record may include one or more formulas that arepopulated from the summary field. For example, a summary may be based onthe results of formulas in the child records. In one embodiment, thesummary may be an aggregate the product of two columns in the childrecord.

Additionally, the function may include various operations to facilitatethe aggregating. For example, in various embodiments, the function mayinclude a record count operation, a sum operation, a smallest valueoperation, a largest value operation, an average (mean) operation, amedian operation, a mode operation, a standard deviation operation, etc.

In this case, a record count operation may count the number of directlyrelated child records. For example, a custom account field tagged “TotalNumber of Contacts” may display a record count of the total number ofcontacts directly related to an account. The sum operation may add thevalues of a single field on directly related child records. For example,a custom account field called “Lifetime Account Value” may examine alldirectly related contracts of an account and add up a “Contract Value”field.

Additionally, a smallest value operation may find the lowest value of asingle field on directly related child records. For example, a customaccount field titled “Customer Since” may examine a “Close Date” fieldof all successful opportunities and display the oldest. The largestvalue operation may find the highest value of a single field on directlyrelated child records. For example, a custom account field called“Highest Contract Value” may examine a “Total Contract Value” field ofall related contracts and display the contract with the largest dollaramount.

It should be noted that the functions used in conjunction with theaggregation may include various datatypes. For example, the datatypesmay include numeric type fields such as a number, currency, and percent,as well as date and time, etc.

As an option, the method 100 may further include determining whetherthere has been a change in a summary field associated with the summarydefinition. In this case, it may be determined whether the changerequires processing of a predetermined number of parent objects, whichmay be part or all of the parent objects. The aggregating may then beperformed in real-time based on the determination. Also, in some cases,a change in the summary field definition may require recomputing thesummary field for some or all parents. In these cases, asynchronousprocessing may be implemented.

In one embodiment, the aggregating may be performed in real-time of thechange and may require processing of less than the predetermined numberof parent objects. In another embodiment, the aggregating may not beperformed in real-time of the change and may require processing of lessthan the predetermined number of parent objects.

FIG. 2 shows a method 200 for aggregating on-demand database servicedata, in accordance with another embodiment. As an option, the presentmethod 200 may be implemented in the context of the functionality ofFIG. 1. Of course, however, the method 200 may be carried out in anydesired environment. The aforementioned definitions may apply during thepresent description.

As shown, it is determined if there is a change in a child object (e.g.a child record). See operation 202. If there is a change in a childobject, processing of summary information of a parent object isinitiated to reflect the change in the child object. See operation 204.

Once the processing is initiated, it is determined whether to implementa synchronous update of the single parent or a delta update of thesingle parent. See operation 206. In the context of the presentdescription, a synchronous update refers to an update where all relevantchild rows may be scanned synchronously and the parent may be updated inthe same transaction as the child. In this case, the parent in questionmay optionally be locked. Additionally, in the context of the presentdescription, a delta update refers to an update where a single childupdate occurs and a new summary may be determined without scanning allchild rows.

If it is determined that a synchronous update is to be performed, thesynchronous update is performed. See operation 208. If it is determinedthat a delta update is to be performed, the delta update is performed.See operation 210.

It is then determined whether to display the summary information. Seeoperation 212. If it is determined to display the summary information,it is further determined whether additional processing is required. Seeoperation 214.

If additional processing is required, the processing is performed. Seeoperation 216. The summary information is then displayed. See operation218.

FIG. 3 shows a method 300 for aggregating on-demand database servicedata, in accordance with another embodiment. As an option, the presentmethod 300 may be implemented in the context of the functionality ofFIGS. 1-2. Of course, however, the method 300 may be carried out in anydesired environment. Again, the aforementioned definitions may applyduring the present description.

As shown, it is determined if there is a change in a summary field orsummary field definition. See operation 302. If it is determined thatthere is a change in the summary field, it is determined whether thechange requires processing of all parents. See operation 304.

If the change does not require the processing of all parents, theprocessing of the change, including aggregation, takes place inreal-time or near real-time. See operation 306. If the change requiresprocessing of all parents, the processing, including aggregation, isqueued for a bulk asynchronous update of all parents. See operation 308.

Using the methods described herein, a new custom field type thataggregates a record count or field value from directly relatedmaster/detail child records may be displayed. In this way, summaryfields may be available everywhere other fields are available, includingreports, list views, and merge fields, etc. In order to work in reportsand list views, the evaluated summary results may be materialized in thesummary field.

In one embodiment, the three evaluation mechanisms described above maybe utilized for updating summary fields. For example, a bulkasynchronous update of all parents may be implemented. In this case, thebulk update may be queued and a metadata definition of the summary fieldmay be marked as dirty, or invalid. As an option, bulk updates mayimplement parent chunking to update a chunk of parent rows with theirsummaries of the relevant child rows. Additionally, all parents in achunk may be locked.

As another option, the synchronous update of a single parent may beimplemented, where all relevant child rows may be scanned synchronouslyand the parent may be updated in the same transaction as the child. As athird option, the delta update of a single parent may be implemented. Ifa summary field is marked as “dirty,” delta updates may not beperformed. Instead a synchronous single parent scan may be performed. Ifa single parent scan is determined to be implemented, it may alwaysexecute, regardless of the dirty or invalid bit setting.

In one embodiment, a running or scheduled bulk update task may becanceled if a new bulk update task is deemed to be caused by a bulkoperation. In this case, a new bulk update task may recompute the samefield and thus obsolete the previous task. The new task may be queuedbefore the old task is removed from the queue.

When the deletion of an object cascades to objects that contribute tosummaries in other objects that are not being cascaded, the summariesmay be recomputed. For example, when deletion of a contact cascades toits activities, the relationship summaries should be recomputed forthose activities. When un-deleting an object, all the summaries affectedby the object, as well as all the cascades, may be recomputed. The listof children being undeleted is not necessarily the same as the list ofchildren originally deleted in the first place.

In one embodiment, roll-up summary definitions may include a filtercondition on the summarized rows. As an option, filters may beimplemented using formulas. In one embodiment, a filter user interfacemay be utilized to define filters. In this case, the filter userinterface may be utilized to generate Boolean formula expressions. Theseexpressions may be used at runtime to generate SQL filter expressionsand for incremental updates to evaluate the filter point-wise in memory.

Thus, filter conditions may be imposed on roll-up summary fields suchthat only specified child records meeting certain criteria areaggregated, as desired. For example, a custom contact field named“Number of Open Cases” may be created that could display the number ofcases related to a contact, but only if cases have not yet been closed.

It should be noted that unit conversions may be performed on informationto be summarized. For example, a data set may include economic dataassociated with various currencies. In this case, any aggregation mayinclude converting the economic data into a common currency. In oneembodiment, the common currency may be a user defined currency.

FIG. 4 shows an interface 400 including a table for aggregatingon-demand database service data when the data includes data of multiplecurrencies, in accordance with one embodiment. As an option, theinterface 400 may be implemented in the context of the functionality ofFIGS. 1-3. Of course, however, the interface 400 may be implemented inany desired environment. Further, the aforementioned definitions mayapply during the present description.

As shown, the interface 400 includes roll-up summary field behavior fordata corresponding to different currencies. Because only one set ofcurrency conversion rates are normally maintained for an organization,all child records may use this single conversion table for aggregatingtheir values to the parent. As an option, the currency of the parentrecord may be used as the currency to which all child records will beconverted.

Every time a conversion rate is updated by an administrator, a massrecalculation of all roll-up summary fields of type “currency” mayoptionally be triggered. On the other hand, workflow, validation, apextriggers, etc. may not be affected by this change. If the currency ofthe parent record is changed, a recalculation of any currency roll-upsummary fields for that record may also optionally be performed. Theseare other cases that a bulk asynchronous recalculation of all parentrows may be performed.

FIGS. 5A-5E show interfaces for creating a new summary field on amaster-detail relationship, in accordance with one embodiment. As anoption, the interfaces may be implemented in the context of thefunctionality of FIGS. 1-4. Of course, however, the interfaces may beimplemented in any desired environment. Again, the aforementioneddefinitions may apply during the present description.

As shown, an interface is displayed such that a user may create a customfield on an object where the field is to be displayed. See FIG. 5A.Because summary fields summarize the values from records on a relatedobject, the object on which the field is created should be on the masterside of a master-detail relationship.

To create a roll-up summary, the user may select the roll-up summaryfield type, and click next. Subsequently, the user may be presented withanother interface where the user may enter a field label, field name, adescription, and other attributes. See FIG. 5B. The user may enter afield label and any other attributes and click next to continue.

After entering the field label and other attributes, the user ispresented with an interface to define a summary calculation. See FIG.5C. Using this interface, the user may select an object on the detailside of a master-detail relationship. In this case, the object on thedetail side includes the records that the user wants to aggregate.

Additionally, the user is able to select the type of summary/aggregationto implement. For example, the user may select a count operation thattotals the number of related records. In other words, the countoperation totals the values in the field the user selected to aggregate.

As another option, the user may select a sum operation that displays thelowest value for all directly-related records of the field the userselected to aggregate. Still yet, the user may select a min or a maxoperation.

Once the user has selected the type of summary/aggregation to implement,the user may enter filter criteria if a selected group of records isdesired in the summary calculation. In the case that an organization ofthe user uses multiple languages, default filter language may be used.Once the user has selected the filter criteria, the user may select nextto continue.

Upon clicking next, another interface may be displayed for establishingfield-level security. See FIG. 5D. For example, the user may set thefield-level security to determine whether the field should be visiblefor specific profiles.

Once the user has established the field-level security, the user mayselect next to continue. Subsequently, an interface may be displayedthat allows the user to choose page layouts to display the field. SeeFIG. 5E. In one embodiment, the field may be added as the last field inthe first two-column section on the page layout. For user custom fields,the field may be automatically added to the bottom of the user detailpage. The user may then have the option to click save to finish or saveand new to create more custom fields.

In this way, roll-up summary fields may calculate values from a set ofrelated records, such as those in a related list. Roll-up summary fieldsmay be created to automatically display a value on a master record basedon the values of records in a detail record, where the detail recordsare directly related to the master. For example, a custom account fieldcalled “Total Invoice Amount” may display the sum of invoice amounts forall related invoice custom object records in the invoices related liston an account.

System Overview

FIG. 6 illustrates a block diagram of an environment 610 wherein anon-demand database service might be used. As an option, any of thepreviously described embodiments of the foregoing figures may or may notbe implemented in the context of the environment 610. Environment 610may include user systems 612, network 614, system 616, processor system617, application platform 618, network interface 620, tenant datastorage 622, system data storage 624, program code 626, and processspace 628. In other embodiments, environment 610 may not have all of thecomponents listed and/or may have other elements instead of, or inaddition to, those listed above.

Environment 610 is an environment in which an on-demand database serviceexists. User system 612 may be any machine or system that is used by auser to access a database user system. For example, any of user systems612 can be a handheld computing device, a mobile phone, a laptopcomputer, a work station, and/or a network of computing devices. Asillustrated in FIG. 6 (and in more detail in FIG. 7) user systems 612might interact via a network with an on-demand database service, whichis system 616.

An on-demand database service, such as system 616, is a database systemthat is made available to outside users that do not need to necessarilybe concerned with building and/or maintaining the database system, butinstead may be available for their use when the users need the databasesystem (e.g., on the demand of the users). Some on-demand databaseservices may store information from one or more tenants stored intotables of a common database image to form a multi-tenant database system(MTS). Accordingly, “on-demand database service 616” and “system 616”will be used interchangeably herein. A database image may include one ormore database objects. A relational database management system (RDMS) orthe equivalent may execute storage and retrieval of information againstthe database object(s). Application platform 618 may be a framework thatallows the applications of system 616 to run, such as the hardwareand/or software, e.g., the operating system. In an embodiment, on-demanddatabase service 616 may include an application platform 618 thatenables creation, managing and executing one or more applicationsdeveloped by the provider of the on-demand database service, usersaccessing the on-demand database service via user systems 612, or thirdparty application developers accessing the on-demand database servicevia user systems 612.

The users of user systems 612 may differ in their respective capacities,and the capacity of a particular user system 612 might be entirelydetermined by permissions (permission levels) for the current user. Forexample, where a salesperson is using a particular user system 612 tointeract with system 616, that user system has the capacities allottedto that salesperson. However, while an administrator is using that usersystem to interact with system 616, that user system has the capacitiesallotted to that administrator. In systems with a hierarchical rolemodel, users at one permission level may have access to applications,data, and database information accessible by a lower permission leveluser, but may not have access to certain applications, databaseinformation, and data accessible by a user at a higher permission level.Thus, different users will have different capabilities with regard toaccessing and modifying application and database information, dependingon a user's security or permission level.

Network 614 is any network or combination of networks of devices thatcommunicate with one another. For example, network 614 can be any one orany combination of a LAN (local area network), WAN (wide area network),telephone network, wireless network, point-to-point network, starnetwork, token ring network, hub network, or other appropriateconfiguration. As the most common type of computer network in currentuse is a TCP/IP (Transfer Control Protocol and Internet Protocol)network, such as the global internetwork of networks often referred toas the “Internet” with a capital “I,” that network will be used in manyof the examples herein. However, it should be understood that thenetworks that the present invention might use are not so limited,although TCP/IP is a frequently implemented protocol.

User systems 612 might communicate with system 616 using TCP/IP and, ata higher network level, use other common Internet protocols tocommunicate, such as HTTP, FTP, AFS, WAP, etc. In an example where HTTPis used, user system 612 might include an HTTP client commonly referredto as a “browser” for sending and receiving HTTP messages to and from anHTTP server at system 616. Such an HTTP server might be implemented asthe sole network interface between system 616 and network 614, but othertechniques might be used as well or instead. In some implementations,the interface between system 616 and network 614 includes load sharingfunctionality, such as round-robin HTTP request distributors to balanceloads and distribute incoming HTTP requests evenly over a plurality ofservers. At least as for the users that are accessing that server, eachof the plurality of servers has access to the MTS' data; however, otheralternative configurations may be used instead.

In one embodiment, system 616, shown in FIG. 6, implements a web-basedcustomer relationship management (CRM) system. For example, in oneembodiment, system 616 includes application servers configured toimplement and execute CRM software applications as well as providerelated data, code, forms, webpages and other information to and fromuser systems 612 and to store to, and retrieve from, a database systemrelated data, objects, and Webpage content. With a multi-tenant system,data for multiple tenants may be stored in the same physical databaseobject, however, tenant data typically is arranged so that data of onetenant is kept logically separate from that of other tenants so that onetenant does not have access to another tenant's data, unless such datais expressly shared. In certain embodiments, system 616 implementsapplications other than, or in addition to, a CRM application. Forexample, system 616 may provide tenant access to multiple hosted(standard and custom) applications, including a CRM application. User(or third party developer) applications, which may or may not includeCRM, may be supported by the application platform 618, which managescreation, storage of the applications into one or more database objectsand executing of the applications in a virtual machine in the processspace of the system 616.

One arrangement for elements of system 616 is shown in FIG. 7, includinga network interface 620, application platform 618, tenant data storage622 for tenant data 623, system data storage 624 for system dataaccessible to system 616 and possibly multiple tenants, program code 626for implementing various functions of system 616, and a process space628 for executing MTS system processes and tenant-specific processes,such as running applications as part of an application hosting service.Additional processes that may execute on system 616 include databaseindexing processes.

Several elements in the system shown in FIG. 6 include conventional,well-known elements that are explained only briefly here. For example,each user system 612 could include a desktop personal computer,workstation, laptop, PDA, cell phone, or any wireless access protocol(WAP) enabled device or any other computing device capable ofinterfacing directly or indirectly to the Internet or other networkconnection. User system 612 typically runs an HTTP client, e.g., abrowsing program, such as Microsoft's Internet Explorer browser,Netscape's Navigator browser, Opera's browser, or a WAP-enabled browserin the case of a cell phone, PDA or other wireless device, or the like,allowing a user (e.g., subscriber of the multi-tenant database system)of user system 612 to access, process and view information, pages andapplications available to it from system 616 over network 614. Each usersystem 612 also typically includes one or more user interface devices,such as a keyboard, a mouse, trackball, touch pad, touch screen, pen orthe like, for interacting with a graphical user interface (GUI) providedby the browser on a display (e.g., a monitor screen, LCD display, etc.)in conjunction with pages, forms, applications and other informationprovided by system 616 or other systems or servers. For example, theuser interface device can be used to access data and applications hostedby system 616, and to perform searches on stored data, and otherwiseallow a user to interact with various GUI pages that may be presented toa user. As discussed above, embodiments are suitable for use with theInternet, which refers to a specific global internetwork of networks.However, it should be understood that other networks can be used insteadof the Internet, such as an intranet, an extranet, a virtual privatenetwork (VPN), a non-TCP/IP based network, any LAN or WAN or the like.

According to one embodiment, each user system 612 and all of itscomponents are operator configurable using applications, such as abrowser, including computer code run using a central processing unitsuch as an Intel Pentium® processor or the like. Similarly, system 616(and additional instances of an MTS, where more than one is present) andall of their components might be operator configurable usingapplication(s) including computer code to run using a central processingunit such as processor system 617, which may include an Intel Pentium®processor or the like, and/or multiple processor units. A computerprogram product embodiment includes a machine-readable storage medium(media) having instructions stored thereon/in which can be used toprogram a computer to perform any of the processes of the embodimentsdescribed herein. Computer code for operating and configuring system 616to intercommunicate and to process webpages, applications and other dataand media content as described herein are preferably downloaded andstored on a hard disk, but the entire program code, or portions thereof,may also be stored in any other volatile or non-volatile memory mediumor device as is well known, such as a ROM or RAM, or provided on anymedia capable of storing program code, such as any type of rotatingmedia including floppy disks, optical discs, digital versatile disk(DVD), compact disk (CD), microdrive, and magneto-optical disks, andmagnetic or optical cards, nanosystems (including molecular memory ICs),or any type of media or device suitable for storing instructions and/ordata. Additionally, the entire program code, or portions thereof, may betransmitted and downloaded from a software source over a transmissionmedium, e.g., over the Internet, or from another server, as is wellknown, or transmitted over any other conventional network connection asis well known (e.g., extranet, VPN, LAN, etc.) using any communicationmedium and protocols (e.g., TCP/IP, HTTP, HTTPS, Ethernet, etc.) as arewell known. It will also be appreciated that computer code forimplementing embodiments of the present invention can be implemented inany programming language that can be executed on a client system and/orserver or server system such as, for example, C, C++, HTML, any othermarkup language, Java™, JavaScript, ActiveX, any other scriptinglanguage, such as VBScript, and many other programming languages as arewell known may be used. (Java™ is a trademark of Sun Microsystems,Inc.).

According to one embodiment, each system 616 is configured to providewebpages, forms, applications, data and media content to user (client)systems 612 to support the access by user systems 612 as tenants ofsystem 616. As such, system 616 provides security mechanisms to keepeach tenant's data separate unless the data is shared. If more than oneMTS is used, they may be located in close proximity to one another(e.g., in a server farm located in a single building or campus), or theymay be distributed at locations remote from one another (e.g., one ormore servers located in city A and one or more servers located in cityB). As used herein, each MTS could include one or more logically and/orphysically connected servers distributed locally or across one or moregeographic locations. Additionally, the term “server” is meant toinclude a computer system, including processing hardware and processspace(s), and an associated storage system and database application(e.g., OODBMS or RDBMS) as is well known in the art. It should also beunderstood that “server system” and “server” are often usedinterchangeably herein. Similarly, the database object described hereincan be implemented as single databases, a distributed database, acollection of distributed databases, a database with redundant online oroffline backups or other redundancies, etc., and might include adistributed database or storage network and associated processingintelligence.

FIG. 7 also illustrates environment 610. However, in FIG. 7 elements ofsystem 616 and various interconnections in an embodiment are furtherillustrated. FIG. 7 shows that user system 612 may include processorsystem 612A, memory system 612B, input system 612C, and output system612D. FIG. 7 shows network 614 and system 616. FIG. 7 also shows thatsystem 616 may include tenant data storage 622, tenant data 623, systemdata storage 624, system data 625, User Interface (U) 730, ApplicationProgram Interface (API) 732, PL/SOQL 734, save routines 736, applicationsetup mechanism 738, applications servers 700 ₁-700 _(N), system processspace 702, tenant process spaces 704, tenant management process space710, tenant storage area 712, user storage 714, and application metadata716. In other embodiments, environment 610 may not have the sameelements as those listed above and/or may have other elements insteadof, or in addition to, those listed above.

User system 612, network 614, system 616, tenant data storage 622, andsystem data storage 624 were discussed above in FIG. 6. Regarding usersystem 612, processor system 612A may be any combination of one or moreprocessors. Memory system 612B may be any combination of one or morememory devices, short term, and/or long term memory. Input system 612Cmay be any combination of input devices, such as one or more keyboards,mice, trackballs, scanners, cameras, and/or interfaces to networks.Output system 6121) may be any combination of output devices, such asone or more monitors, printers, and/or interfaces to networks. As shownby FIG. 7, system 616 may include a network interface 620 (of FIG. 6)implemented as a set of HTTP application servers 700, an applicationplatform 618, tenant data storage 622, and system data storage 624. Alsoshown is system process space 702, including individual tenant processspaces 704 and a tenant management process space 710. Each applicationserver 700 may be configured to tenant data storage 622 and the tenantdata 623 therein, and system data storage 624 and the system data 625therein to serve requests of user systems 612. The tenant data 623 mightbe divided into individual tenant storage areas 712, which can be eithera physical arrangement and/or a logical arrangement of data. Within eachtenant storage area 712, user storage 714 and application metadata 716might be similarly allocated for each user. For example, a copy of auser's most recently used (MRU) items might be stored to user storage714. Similarly, a copy of MRU items for an entire organization that is atenant might be stored to tenant storage area 712. A UI 730 provides auser interface and an API 732 provides an application programmerinterface to system 616 resident processes to users and/or developers atuser systems 612. The tenant data and the system data may be stored invarious databases, such as one or more Oracle™ databases.

Application platform 618 includes an application setup mechanism 738that supports application developers' creation and management ofapplications, which may be saved as metadata into tenant data storage622 by save routines 736 for execution by subscribers as one or moretenant process spaces 704 managed by tenant management process 710 forexample. Invocations to such applications may be coded using PL/SOQL 734that provides a programming language style interface extension to API732. A detailed description of some PL/SOQL language embodiments isdiscussed in commonly owned U.S. Provisional Patent Application60/828,192 entitled, “PROGRAMMING LANGUAGE METHOD AND SYSTEM FOREXTENDING APIS TO EXECUTE IN CONJUNCTION WITH DATABASE APIS,” by CraigWeissman, filed Oct. 4, 2006, which is incorporated in its entiretyherein for all purposes. Invocations to applications may be detected byone or more system processes, which manages retrieving applicationmetadata 716 for the subscriber making the invocation and executing themetadata as an application in a virtual machine.

Each application server 700 may be communicably coupled to databasesystems, e.g., having access to system data 625 and tenant data 623, viaa different network connection. For example, one application server 700₁ might be coupled via the network 614 (e.g., the Internet), anotherapplication server 700 _(N-1) might be coupled via a direct networklink, and another application server 700 _(N) might be coupled by yet adifferent network connection. Transfer Control Protocol and InternetProtocol (TCP/IP) are typical protocols for communicating betweenapplication servers 700 and the database system. However, it will beapparent to one skilled in the art that other transport protocols may beused to optimize the system depending on the network interconnect used.

In certain embodiments, each application server 700 is configured tohandle requests for any user associated with any organization that is atenant. Because it is desirable to be able to add and remove applicationservers from the server pool at any time for any reason, there ispreferably no server affinity for a user and/or organization to aspecific application server 700.

In one embodiment, therefore, an interface system implementing a loadbalancing function (e.g., an F5 Big-IP load balancer) is communicablycoupled between the application servers 700 and the user systems 612 todistribute requests to the application servers 700. In one embodiment,the load balancer uses a least connections algorithm to route userrequests to the application servers 700. Other examples of loadbalancing algorithms, such as round robin and observed response time,also can be used. For example, in certain embodiments, three consecutiverequests from the same user could hit three different applicationservers 700, and three requests from different users could hit the sameapplication server 700. In this manner, system 616 is multi-tenant,wherein system 616 handles storage of, and access to, different objects,data and applications across disparate users and organizations.

As an example of storage, one tenant might be a company that employs asales force where each salesperson uses system 616 to manage their salesprocess. Thus, a user might maintain contact data, leads data, customerfollow-up data, performance data, goals and progress data, etc., allapplicable to that user's personal sales process (e.g., in tenant datastorage 622). In an example of a MTS arrangement, since all of the dataand the applications to access, view, modify, report, transmit,calculate, etc., can be maintained and accessed by a user system havingnothing more than network access, the user can manage his or her salesefforts and cycles from any of many different user systems. For example,if a salesperson is visiting a customer and the customer has Internetaccess in their lobby, the salesperson can obtain critical updates as tothat customer while waiting for the customer to arrive in the lobby.

While each user's data might be separate from other users' dataregardless of the employers of each user, some data might beorganization-wide data shared or accessible by a plurality of users orall of the users for a given organization that is a tenant. Thus, theremight be some data structures managed by system 616 that are allocatedat the tenant level while other data structures might be managed at theuser level. Because an MTS might support multiple tenants includingpossible competitors, the MTS should have security protocols that keepdata, applications, and application use separate. Also, because manytenants may opt for access to an MTS rather than maintain their ownsystem, redundancy, up-time, and backup are additional functions thatmay be implemented in the MTS. In addition to user-specific data andtenant-specific data, system 616 might also maintain system level datausable by multiple tenants or other data. Such system level data mightinclude industry reports, news, postings, and the like that are sharableamong tenants.

In certain embodiments, user systems 612 (which may be client systems)communicate with application servers 700 to request and updatesystem-level and tenant-level data from system 616 that may requiresending one or more queries to tenant data storage 622 and/or systemdata storage 624. System 616 (e.g., an application server 700 in system616) automatically generates one or more SQL statements (e.g., one ormore SQL queries) that are designed to access the desired information,System data storage 624 may generate query plans to access the requesteddata from the database.

Each database can generally be viewed as a collection of objects, suchas a set of logical tables, containing data fitted into predefinedcategories. A “table” is one representation of a data object, and may beused herein to simplify the conceptual description of objects and customobjects according to the present invention. It should be understood that“table” and “object” may be used interchangeably herein. Each tablegenerally contains one or more data categories logically arranged ascolumns or fields in a viewable schema. Each row or record of a tablecontains an instance of data for each category defined by the fields.For example, a CRM database may include a table that describes acustomer with fields for basic contact information such as name,address, phone number, fax number, etc. Another table might describe apurchase order, including fields for information such as customer,product, sale price, date, etc. In some multi-tenant database systems,standard entity tables might be provided for use by all tenants. For CRMdatabase applications, such standard entities might include tables forAccount, Contact, Lead, and Opportunity data, each containingpre-defined fields. It should be understood that the word “entity” mayalso be used interchangeably herein with “object” and “table”.

In some multi-tenant database systems, tenants may be allowed to createand store custom objects, or they may be allowed to customize standardentities or objects, for example by creating custom fields for standardobjects, including custom index fields. U.S. patent application Ser. No.10/817,161, filed Apr. 2, 2004, entitled “CUSTOM ENTITIES AND FIELDS INA MULTI-TENANT DATA BASE SYSTEM,” which is hereby incorporated herein byreference, teaches systems and methods for creating custom objects aswell as customizing standard objects in a multi-tenant database system.In certain embodiments, for example, all custom entity data rows arestored in a single multi-tenant physical table, which may containmultiple logical tables per organization. It is transparent to customersthat their multiple “tables” are in fact stored in one large table orthat their data may be stored in the same table as the data of othercustomers.

It should be noted that any of the different embodiments describedherein may or may not be equipped with any one or more of the featuresset forth in one or more of the following published applications:US2003/0233404, titled “OFFLINE SIMULATION OF ONLINE SESSION BETWEENCLIENT AND SERVER,” filed Nov. 4, 2002; US2004/0210909, titled “JAVAOBJECT CACHE SERVER FOR DATABASES,” filed Apr. 17, 2003, now issued U.S.Pat. No. 7,209,929; US2005/0065925, titled “QUERY OPTIMIZATION IN AMULTI-TENANT DATABASE SYSTEM,” filed Sep. 23, 2003; US2005/0223022,titled “CUSTOM ENTITIES AND FIELDS IN A MULTI-TENANT DATABASE SYSTEM,”filed Apr. 2, 2004; US2005/0283478, titled “SOAP-BASED WEB SERVICES IN AMULTI-TENANT DATABASE SYSTEM,” filed Jun. 16, 2004; and/orUS2006/0206834, titled “SYSTEMS AND METHODS FOR IMPLEMENTINGMULTI-APPLICATION TABS AND TAB SETS,” filed Mar. 8, 2005; which are eachincorporated herein by reference in their entirety for all purposes.

While the invention has been described by way of example and in terms ofthe specific embodiments, it is to be understood that the invention isnot limited to the disclosed embodiments. To the contrary, it isintended to cover various modifications and similar arrangements aswould be apparent to those skilled in the art. Therefore, the scope ofthe appended claims should be accorded the broadest interpretation so asto encompass all such modifications and similar arrangements.

1. A method, comprising: receiving a summary definition including afunction for summarizing data and information specifying a plurality ofchild records of an on-demand database service; aggregating the datafrom the child records to form an aggregate based on the summarydefinition; displaying the aggregate, in response to a request forviewing the aggregate.
 2. The method of claim 1, wherein the summarydefinition is associated with a roll-up summary field.
 3. The method ofclaim 1, wherein the summary definition is associated with a parentrecord.
 4. The method of claim 1, wherein the aggregating is performed,at least in part, before the request to view the aggregate is received.5. The method of claim 1, wherein a first portion of the aggregating isperformed before the request is received, and a second portion of theaggregating is performed after the request is received.
 6. The method ofclaim 1, wherein the aggregating is performed, in response to a changein the data of the child records.
 7. The method of claim 1, wherein thesummary definition specifies a filter to determine the child records tobe selected.
 8. The method of claim 1, wherein the data of only thespecified child records are aggregated.
 9. The method of claim 1,wherein the child records include one or more formulas that arepopulated from summary fields.
 10. The method of claim 1, wherein aparent record includes a formula populated from a summary field.
 11. Themethod of claim 1, and further comprising determining whether there hasbeen a change in a summary field associated with the summary definition.12. The method of claim 11, and further comprising determining whetherthe change requires processing of a predetermined number of parentobjects.
 13. The method of claim 12, wherein the predetermined number ofparent objects include all of the parent objects.
 14. The method ofclaim 12, wherein the aggregating is performed in real-time based on thedetermination.
 15. The method of claim 14, wherein the aggregating isperformed in real-time of the change and requires processing of lessthan the predetermined number of parent objects.
 16. The method of claim14, wherein the aggregating is not performed in real-time of the changeand requires processing of less than the predetermined number of parentobjects.
 17. The method of claim 1, wherein the on-demand databaseservice includes a multi-tenant on-demand database service.
 18. Amachine-readable medium carrying one or more sequences of instructionswhich, when executed by one or more processors, cause the one or moreprocessors to carry out the steps of: receiving a summary definitionincluding a function for summarizing data and information specifying aplurality of child records of an on-demand database service; aggregatingthe data from the child records to form an aggregate based on thesummary definition; displaying the aggregate, in response to a requestfor viewing the aggregate.
 19. An apparatus, comprising: a processor;and one or more stored sequences of instructions which, when executed bythe processor, cause the processor to carry out the steps of: receivinga summary definition including a function for summarizing data andinformation specifying a plurality of child records of an on-demanddatabase service; aggregating the data from the child records to form anaggregate based on the summary definition; displaying the aggregate, inresponse to a request for viewing the aggregate.
 20. A method fortransmitting code for use in a multi-tenant database system on atransmission medium, the method comprising: transmitting code forreceiving a summary definition including a function for summarizing dataand information specifying a plurality of child records of an on-demanddatabase service; transmitting code for aggregating the data from thechild records to form an aggregate based on the summary definition;transmitting code for displaying the aggregate, in response to a requestfor viewing the aggregate.